Metodologías modernas de desarrollo de Sistemas de Información (página 2)
En la década de los 80s, los grandes avances
tecnológicos permitieron el desarrollo de SI de menor
costo y mayor
potencia que los
anteriores. Empleados de todos los niveles comenzaron a utilizar
computadoras personales para realizar las mas diversas tareas; ya
no dependían solo del departamento de sistemas de
información para resolver todas sus necesidades
informativas. La gente se dio cuenta entonces de que era posible
utilizar los sistemas de computación en apoyo a actividades
adicionales de toma de
decisiones. Y se generaron os Sistemas de Apoyo para la toma
de Decisiones. Las computadoras entonces cambiaron a ser de
quinta generación. En las que se cuentan los procesadores
8080, 8086, 80286. Los sistemas de información que
sobresalieron son: Sistemas de Soporte a Decisiones, Pago a
Usuarios Finales y Planeación Estratégica. Surge
la
Administración de Recursos de Información y los
Centros de Información
A partir de los 90s surgen los procesadores 80386,
80486, y Microprocesadores Pentium. En esta
se han conseguido importantes avances tanto en la IA como en los
SE. El valor
excepcional de los sistemas
expertos radica en el hecho de que permiten a los
organizadores proveerse de y utilizar el saber de expertos y
especialistas. Por lo tanto, años de experiencia y
habilidades especificas no se pierden del todo cuando un experto
muere, se retira o cambia de trabajo. Son aplicables a casi
cualquier campo o disciplina.
Los temas principales en los sistemas de información son:
Servicios de
Información, Estaciones de Trabajo y Administración de datos
centralizados.
Cuatro cambios ocurrieron a través de las
décadas pasadas y ahora son factores claves para los
90s:
- El concepto en la
aproximación orientada a objetos en el campo de software ha ido
madurando durante dos decadas, y la atención ha ido gradualmente cambiando
hacia los asuntos de codificación y a los asuntos de
diseño y analisis. - La tecnología para construir sistemas ha ido
haciendose mas poderosa. Ideas acerca de diseño han
influido por ideas preconcebidas acerca de como uno podria
escribir codigo; e
ideas acerca de codificacion son fuertemente influenciadas por
el lenguaje de
programación que esta disponible. Era difícil
pensar acerca de programación estructurada cuando los
lenguajes a elegir eran ensambladores y FORTRAN; las cosas se
volvieron mas fáciles con Pascal, PL-1, y
ALGOL. Similarmente, fue difícil pensar en programar en
la moda de
Orientación a Objetos cuando el leguaje a elegir era
COBOL o el plano C; se hizo mas fácil con C++ y
Samlltalk. - Los sistemas construidos hoy en día son
diferentes de como eran hace diez o veinte años atras:
son largos, muy complejos y muy volátiles. Una
aproximación orientada a objetos para el análisis
y el diseño es probable conducirlo a un sistema mas
estable. También ahora sistemas interactivos requieren
mas atención a la interface de usuarios en
comparación al proceso de
sistemas de texto
desarrollados en los 70s. Una aproximación orientado a
objetos para tales sistemas –desde análisis hasta
diseño y codificación- es un método
mas natural para lidiar con tales sistemas orientados a
usuarios. - Los sistemas construidos hoy en día son mas
"dominio-orientado" que los sistemas construidos
en los 70s y 80s. La complejidad funcional es menos preocupante
de como lo era antes; el modelado de datos se ha convertido en
una prioridad moderada; a tomado una prioridad alta el modelar
la comprensión del dominio del problema y las
responsabilidades del sistema.
En el 2000 la información ha ejercido un profundo
impacto en la sociedad, al
grado de que hay quienes llaman a esta época la Era de la
Información. La sociedad industrial ha dado paso a una
nueva sociedad, en donde la mayoría de las personas
trabajan con información en lugar de producir bienes. Los
procesadores principales son los Pentium. Y el tema principal en
Sistemas de Información es el Internet, y los Sistemas de
Información de la Linea del Frente.
3. CONCEPTOS BASICOS DE ORIENTACION A
OBJETOS
Qué es Orientado a Objetos?
Significa que el sistema se organiza como una
colección de objetos que interactúan entre
sí y que contienen tanto estructuras de
datos como un comportamiento.
Esto se opone a la programación convencional, en
la cual las estructuras de datos y el comportamiento solamente
estan relacionadas de forma débil, ya que estos se enfocan
principalmente a las funciones.
Objeto.
Los objetos son las cosas físicas y conceptuales
que encontramos en el universo
alrededor de nosotros. Hadware, software, documentos, seres
humanos, los conceptos son todos los ejemplos de los
objetos.
Características de los Objetos.
Identidad.
Los datos estan cuantificados en entidades discretas y
distinguibles denominadas objetos. Ejem una televisión, una bicicleta, un árbol.
Los objetos pueden ser concretos, como un archivo en un
sistema de archivos, o bien
conceptuales como la política de planificación en un sistema operativo
con multiprocesos. Cada objeto posee su propia identidad
inherente. En otras palabras: dos objetos seran distintos aun
cuando los valores de
todos sus atributos (tales como el nombre y el tamaño)
sean idénticos.
Clasificación. Significa que los objetos
con la misma estructura de
datos (atributos) y comportamiento (operaciones) se
reunen para formar una clase. La selección
de clases es arbitraria y depende de la
aplicación.
Objetos: Bicicleta de montaña, Bicicleta de
carreras, Bicicleta de niños
Clase Bicicleta:
Atributos: Tamaño del cuadro, tamaño de
rueda, material, marca,
velocidad
Operaciones: mover, reparar, cambiar
velocidad
Objetos: Triangulo, Cuadrado, Octagono
Clase Poligonos:
Atributos: vertices, color del borde,
color del interior
Operaciones: dibujar, borrar, mover
Polimorfismo. Significa que una misma
operación puede comportarse de modos distintos en
distintas clases. La operación mover por ejem, se puede
comportar de modo distinto en las clases Ventana y Pieza de
ajedrez. Una
operación es una acción o una transformación
que se lleva a cabo o que se aplica a un objeto. Justificar a la
derecha, visualizar y mover son ejemplos de operaciones. Una
implementación específica de una operación
por parte de una cierta clase es lo que se denomina
método. Dado que los operadores orientados a
objetos son polimórficos es posible que haya más de
un método que lo implemente.
En el mundo real una operación es simplemente,
una abstracción de comportamiento análogo entre
distintas clases de objetos. Cada objeto "sabe" llevar a cabo sus
propias operaciones. Sin embargo, en un lenguaje orientado a
objetos es este el que selecciona automaticamente el
método correcto para implementar una operación
basandose en el nombre de la operación y en la clase del
objeto que esta siendo afectado. El usuario de una
operación no necesita ser consciente del número de
métodos que existen para implementar una cierta
operación polimórfica. Se pueden añadir
nuevas clases sin modificar el código
existente, siempre y cuando se proporcionen métodos para
todas las operaciones aplicables a las nuevas clases.
Herencia. Es compartir atributos y operaciones
entre clases tomando como base una relación
jerárquica. En términos generales se puede definir
una clase que después se irá refinando
sucesivamente para producir subclases. Todas las subclases poseen
o heredan, todas y cada una de las popiedades de su superclase y
añaden, además, sus propiedades exclusivas. No es
necesario repetir las propiedades de las superclases en cada
subclase. Por ejem Ventanadedesplazamiento y ventanafija son
subclases de ventana. Ambas subclases heredan las propiedades de
ventana tales como una región visible de la pantalla. La
ventanadedesplazamiento añade una barra de desplazamiento
y un ascensor. La capacidad de sacar factor común a las
propiedades de varias clases en una superclase común y de
heredar las propiedades de la superclase puede reducir
muchísimo la repteción en el diseño y en los
programas
siendo una de las ventajas pricipales de un sistema orientado a
objetos.
Metodología. Conjunto de métodos
empleados para el desarrollo de sistemas
automatizados.
Una metodología completa es algo más que
una notación, un proceso, y herramientas.
Además de una "notación, de un proceso, y de
herramientas," estas "metodologías completas"
proporcionan:
- Guías para estimar costos,
- Manejo del proyecto en
las tareas y entregas, - Medidas y métricas,
- Formas definidas y dirección en las entregas de la
construcción, - Políticas y procedimientos para garantizar la calidad del
software, - Descripciones de los roles y programas de entrenamiento
detallados, - Ejemplos totalmente trabajados,
- Ejercicios de entrenamiento,
- Técnicas para adaptar el método,
y - Técnicas definidas
5.
EL ENFOQUE DE ESTA INVESTIGACION
Este trabajo consiste en una comparación de
modernas metodologías de desarrollo de sistemas orientados
a objetos en las que se identificará y cuantificará
la ayuda de estas para el proceso de desarrollo.
Debido a que a la fecha ninguna de las
metodologías que se van a comprar cumplen completamente
con las características mencionadas anteriormente,
ya que falta mucho trabajo por hacer para que sean unas
metodologías completas. La comparación se hace con
ese conocimiento y
entonces "metodología" se considera tambien como un
método.
Las metodologías a comparar, ordenadas
alfabéticamente son:
- Berard 1992,
- Booch 1991,
- Coad y Yourdon 1990,
- Embley y Kurtz 1990,
- Martin y Odell 1992,
- Rumbaugh 1991,
- Shlaer y Mellor 1992, y
- Wirfs-Brock 1990
En esta comparación se consideran cuatro
áreas específicamente:
- Conceptos
- Esta sección cita de la ayuda particular
del método y de los contrastes para los
términos dentro de cada método. Los
términos tales como objeto, clase, metaclases, y
operación se comparan.
- Esta sección cita de la ayuda particular
- Notaciones
- Muchos métodos requieren crear
descripciones abstractas, o modelos gráficos, del sistema en el
análisis y/o diseño. Se construyen estos
modelos usando una cierta forma de notación. La
semántica de la notación proporciona el
significado a los modelos. Las notaciones, para ser
eficaces en el desarrollo de grandes sistemas, requieren
un mecanismo para dividir los componentes en "pedazos
más manejables".
- Muchos métodos requieren crear
- Procesos
- Cuanto del ciclo de vida del desarrollo de los
sistemas es cubierto por el método, y qué
adaptación o heurística está
disponible para el proceso del método. Es evaluada
la cobertura al ciclo de vida. Comprobar que elementos
del desarrollo del software se manejan dentro del
método. Cada metodología puede tener
elementos que sean útiles a una parte del ciclo de
vida del desarrollo. Las fases del ciclo de vida se
definen de la siguiente manera: - El Análisis es esa parte de ciclo de
vida que describe las características exterior
observables del sistema, ejem, funcionalidad,
funcionamiento, capacidad. Esta descripción incluye normalmente
los modelos que representan la construcción
lógica de los sistemas, y su
colocación dentro de un ambiente de sistema. - El Diseño es la parte del ciclo de
vida que prepara definiciones en cuanto a cómo
el sistema logrará sus requerimientos. Los
modelos preparados en análisis se refinan, o
se transforman, en los modelos del diseño que
representan la naturaleza física del producto de software. - La implementación es la parte del
ciclo de vida que convierte los modelos desarrollados
del diseño en el software ejecutable dentro
del ambiente del sistema. Este implica la
codificación de las unidades del programa, de la generación
automatizada del código, o del montaje de los
componentes reutilizables ya construidos y probados
del código de una biblioteca interna de la
reusabilidad. - La prueba se centra en asegurarse de que
cada una de las entregas a partir de cada fase cumple
con las necesidades indentificadas por el/los
usuarios. - El domininio del análisis direcciona
la busqueda y aplicación del dominio y la
identificación, documentación,
construcción y prueba y demostración de
los componentes reutilizables utiles en el dominio.
Aunque esto no es una actividad del ciclo de vida del
proyecto, es una parte importante de considerar en la
ayuda brindada por la metodología.
- El Análisis es esa parte de ciclo de
- Se evalúan después las
características o las cualidades del proceso del
método. Las características de un proceso
sirven para medir la capacidad de repetición del
método y flexibilidad. Las características
define la secuencia de pasos, de entradas requeridas y de
salidas, papeles implicados, así como la
interacción con otros pasos. Los pasos opcionales
deben ser identificados claramente. La heurística
y los mecanismos disponibles para la traceabilidad, la
verificación, y la validación del proceso
son también cualidades deseables de un proceso
bien definido.
- Cuanto del ciclo de vida del desarrollo de los
- Pragmática
La pragmática de una metodología
consiste en:
- Recursos: ¿Qué recursos disponibles
hay dentro de la ayuda del método? ¿Existen un
libros disponibles? ¿Establecen a los grupos de
usuarios? ¿El entrenamiento y la consulta es ofrecida
por el vendedor y/o los terceros? ¿Además,
están las herramientas automatizadas (herramientas
CASE) disponibles en la ayuda del
método? - Conocimientos Requeridos: ¿Cuál es el
background requerido de los que aprenden el método?
Una característica que distingue de muchos
métodos es el nivel de la sofisticación
matemática requerido para explotar
completamente el método. ¿El método
asume conocimiento en una cierta disciplina? - Utilización del lenguaje: ¿El
método guía a un lenguaje en particular?
Algunos métodos son específicos a COBOL o al
Ada, mientras que otros métodos tienen aplicabilidad
más general.
La expectativa de cualquier comparación de la
metodología es que proporcionará una base para
desechar las metodologías que no parecen dar valor
dependiendo de la situación. Esta comparación
maneja esta expectativa. Planteando preguntas de las
metodologías presentadas y usando los resultados
documentados para contestar a las necesidades particulares. Estas
preguntas sirven como punto que partida para una
investigación posterior. Una muestra de las
preguntas incluye:
- "Deseo aprender sobre el desarrollo orientado al
objeto en un sentido general. El proceso del desarrollo
orientado al objeto del software y de la disponibilidad de
herramientas no es realmente muy importante para mí en
este tiempo.
Apenas quiero informacion sobre objetos." - "Tengo que iniciar un gran proyecto que implique
veinte personas, fuera de consultores, y es crítico
para el éxito de nuestra
compañía. Qué métodos son
apropiados para mí?" - "Mi proyecto requiere el uso del lenguaje
Smalltalk. Qué métodos son apropiados
considerando que el
lenguaje de programación se ha seleccionado ya
para mi proyecto?"
En esta sección se cita a cada metodología
para comprarar la opinión de cada autor de un
número de conceptos orientados al objeto.
A. DEFINICIÓN DEL "OBJETO" EN CADA
METODOLOGIA
Berard 1992.
Un objeto que se utiliza para crear las instancias, es
decir, una plantilla, descripción, patrón, o
"modelo" un una
categoría o colección de artículos muy
similares. Entre otras cosas, una clase describe el interfaz que
los estos artículos presentarán al mundo exterior,
los métodos, las constantes, y las excepciones es decir,
disponibles y apropiados. Una clase representa una
abstracción de los artículos. Una clase es
realmente una familia de clases
muy de cerca relacionadas. La clase es un concepto recurrente.
Específicamente, podemos definir clases como un compuesto
de otras clases (es decir, las clases compuestas
heterogéneas y clases compuestas homogéneas), en
términos de sí mismo (una clase recurrentemente
definida), como herencia de
características de unas o más otras clases (es
decir, los superclasses de la clase), y como abastecimiento de
características a otras clases (es decir, las subclases de
la clase). En algunos lugares, se definen las clases como "el
sistema de todos las instancias de un tipo," y del término
"tipo" se da la definición antedicha para la
clase.
Booch 1991.
Algo a lo que se le pueden hacer cosas. Un objeto tiene
estado,
comportamiento, e identidad; la estructura y
el comportamiento de objetos similares se definen en su clase
común. Los términos instancia y objeto son
intercambiables.
Coad y Yourdon 1990.
Una abstracción de algo en un dominio del
problema, reflejando las capacidades de un sistema a mantener la
información de este, interactúa
recíprocamente con esta información, o ambas
(interactuar y mantener); una encapsulación de los
valores
atributos y sus usos exclusivos (sinónimo: una
instancia)
Embley y Kurtz 1990.
Un objeto es una persona, un lugar, o una cosa. Un
objeto puede ser físico o conceptual… La idea es que un
objeto es una sola entidad o noción. Cada objeto es un
individuo único. Un objeto se puede relacionar con o
componer de otros objetos, pero cada objeto es
único.
Martin y Odell 1992.
Cualquier cosa a la cual un concepto, o tipo de objeto,
se aplica – una instancia de un concepto o tipo de objeto.
En OOPLs, es cualquier instancia de una clase."
Rumbaugh 1991.
Definimos un objeto como un concepto, una
abstracción, o cosa con límites
para el problema actual. Los objetos responden a dos
propósitos: Promueven la comprensión del mundo
verdadero y proporcionan una base práctica para la puesta
en práctica de la
computadora. La descomposición de un problema en
objetos depende del juicio y de la naturaleza del problema. No
hay una representación correcta.
Shlaer y Mellor 1992.
Un objeto es una abstracción de un sistema de
cosas del mundo real, tales como:
- todas las cosas en el sistema – las instancias
– tenga las mismas características, y - todas las instancias están conforme y se
conforman con el mismo sistema de reglas y políticas…
Un objeto en OOA representa un solo caso típico
pero sin especificar algo en el mundo verdadero – cualquier
avión, no importa cual, mientras sea representativo. El
analista orientado al objeto distingue este concepto de un caso
específico: Avión número 8945, una fuerza
aérea, o un avión de Aeromexico, por
ejemplo.
Wrifs-Brock 1990.
Los objetos saben ciertos datos sobre sí mismos
(como por ejemplo, una persona sabe los colores de su
pelo y ojos), y los objetos saben como hacer ciertas funciones
(asi como una persona sabe comprar en el mercado o hacer su
trabajo).
En un sentido, un objeto se puede ver como una
declaración, que cierto conocimiento y ciertas operaciones
están relacionados conceptualmente con otro, de modo que
tenga sentido el unirlos.
ANALISIS
En las definciones del término "Objeto",
se concluye lo siguiente:
Indica que ciertos métodos integran la
mención de abstracción a sus definiciones del
objeto, y otros consideran unicidad e identidad como
crítica (solamente Rumbaugh menciona ambos).
Además, la mención el comportamiento y estado se
percibe limitada a esos métodos el centrarse en
unicidad.
Metodología | Mención de | Unicidad o | Comportamiento o | Estado |
Berard | X | X | ||
Booch | X | X | X | |
Coad y Yourdon | X | X | ||
Embley | X | |||
Martin y Odell | X | |||
Rumbaugh | X | |||
Shlaer y Mellor | X | |||
Wirfs-Brock | X | X | X |
B. DEFINICIÓN DE "CLASE" EN CADA
METODOLOGIA
Berard 1992.
Un objeto el cual es utilizado para crear instancias, es
decir, una plantilla, descripción, patrón, o
"modelo" de una categoría o de una colección de
artículos muy similares. Entre otras cosas, una clase
describe la interfaz que los artículos presentarán
al mundo exterior, ejem. los métodos apropiados y
disponibles, las constantes, y las excepciones. Una clase
representa una abstracción de los artículos. Una
clase puede a si misma darse parámetros (ejem, representa
realmente una familia de clases muy estrechamente relacionadas),
a esto le llamamos dar parametos a la clase. Clase es un concepto
recursivo. Específicamente, podemos definir clases como un
compuesto de otras clases (es decir, clases compuestas
heterogéneamente y clases compuestas
homogéneamente), en términos de sí mismo
(una clase definida recursivamente), como características
de herencia de una o más clases (es decir, los
superclasses de la clase), y como abastecimiento de
características a otras clases (es decir, las subclases de
la clase). En algunos lugares, las clases se definen como "el
conjunto de todas los instancias de un tipo," y del
término "tipo" se da la definición para
clase.
Booch 1991.
Un conjunto de objetos que comparten una estructura
común y un comportamiento común. Los
términos clase y tipo son generalmente (pero no siempre)
intercambiables; y una clase es un concepto levemente distinto a
tipo, en el hecho que acentúa la importancia de
jerarquías de clases.
Coad y Yourdon 1990.
Una descripción de uno o más objetos con
un conjunto uniforme de cualidades y de servicios, incluyendo una
descripción de cómo crear nuevos objetos en la
clase.
Clase-Objeto. Un significado del término "una
clase y los objetos en esa clase."
Embley y Kurtz 1990.
Identificación de conjunto de objetos que
pertenecen juntos por una cierta razón lógica
llamada clasificación. En OSA, un sistema de objetos que
pertenecen juntos por una cierta razón lógica se le
llama clase del objeto. El modelo de la Objeto-Relacion insita a
los analistas a que organicen objetos en clases del objeto. Cada
clase del objeto tiene un nombre genérico y denota a
cualquier miembro de la clase del objeto. Así, en un ORM,
una clase del objeto con nombre X señala una
clasificación de los objetos cada uno de los cuales se
considera ser un X. Como cada objeto en clase del objeto X es un
X, los objetos en la clase son semejantes, por lo menos en un
cierto sentido.
Martin y Odell 1992.
Una implementación de un concepto o de un tipo de
objeto. En lenguajes de programación OO, los tipos de datos
abstractos se llaman clases. En matemáticas, el significado de la clase es
similar a el de sistema. El significado de la definición
de OOPL de la clase se presentó de la definición
matemática.
Rumbaugh 1991.
Una clase del objeto describe un grupo de
objetos con las características similares (cualidades), el
comportamiento común (operaciones), relaciones comunes a
otros objetos, y la semántica común. La persona, la
compañía, el animal, el proceso, y la ventana son
todas las clases del objeto.
Shlaer y Mellor 1992.
No provee una definición explicita de
"clase"
Wrifs-Brock 1990.
Los objetos que comparten el mismo comportamiento se
dice que pertenecen a la misma clase. Una clase es una
especificación genérica para un número
arbitrario de objetos similares. Se puede pensar en una clase
como plantilla para una clase específica de
objeto.
ANALISIS
Mientras que el método de Shlaer y de Mellor
utiliza diagramas de la
clase y hace la mención significativa del término
"clase" en su aproximación, no proveen ninguna
definición explícita de la clase. Otra nota es que,
Rumbaugh menciona que una clase debe identificar sus relaciones
con otras clases, mientras que Embley menciona que el modelo de
la Objeto-Relacion es útil en identificar clases. Estos
dos métodos difieren de los otros métodos en su
enfoque en relaciones como fundamental para el uso del
término "clase."
Metodología | Mención de | Mención de | Mención de | Estado | Relaciones |
Berard | X | X | X | ||
Booch | X | X | |||
Coad y Yourdon | X | X | |||
Embley | X | X | |||
Martin y Odell | X | X | |||
Rumbaugh | X | X | X | X | |
Shlaer y Mellor | |||||
Wirfs-Brock | X |
C. DEFINICIÓN DE "OPERACION" EN CADA
METODOLOGIA
Berard 1992.
Una acción que es afectada por, o requerida por
un objeto. Las operaciones pueden ser selectoras, constructivas,
o iterativas. Una operación es contenida en la interfaz
del objeto y tiene sus detalles descritos en un método
correspondiente. Las operaciones pueden ser compuestas, es decir,
integrada por otras operaciones. Sin embargo no es alentada, la
encapsulación de operaciones compuestas dentro de la
interfaz a un objeto.
Booch 1991.
Una cierta acción que un objeto realiza sobre
otro para sacar una reacción. Todas las operaciones sobre
un objeto específico se pueden encontrar en subprogramas
libres y funciones o métodos. Los términos mensaje,
método, y operación son generalmente
intercambiables.
Coad y Yourdon 1990.
Un servicio es un
comportamiento específico que un objeto es responsable de
exhibir.
Embley y Kurtz 1990.
Además de estados y de transiciones entre
estados, también deseamos modelar las acciones que
un objeto realiza. Una acción puede causar
acontecimientos, crear o destruir objetos y relaciones, observar
objetos y relaciones, y enviar o recibir mensajes.
"Ponemos acciones en dos categorías en OSA:
acciones no-interrumpibles y acciones interrumpibles. Las
acciones no-interrumptibles son las acciones que el analista
espera correr al terminar a menos que ocurran las excepciones o
los fallos del sistema. Las acciones interrumpibles pueden ser
suspendidas antes de que acaben de ejecutarse y puedan reasumir
la ejecución despues. En OSA, pensamos en las acciones
asociadas a transiciones como no-interrumptible, mientras que las
acciones asociadas a los estados son interrumpibles."
Martin y Odell 1992.
Un proceso que se puede solicitar como unidad. Un solo
paso que se realiza en una serie de pasos. Las operaciones pueden
o pueden no cambiar el estado de
un objeto. Las funciones son las operaciones que no cambian el
estado. Sin embargo, en un esquema del acontecimiento, las
operaciones que dan lugar a acontecimientos cambian estados (y se
podrían más correctamente llamar las
operaciones-cambia-estados).. Sin embargo cada operación
estado-cambia puede estar como transacción. Una
transacción es un proceso o una serie de procesos que
actúan como unidad para cambiar el estado de un objeto.
Los casos de operaciones se llaman operaciones invocadas. La
especificación de cómo una operación debe
ser realizada se llama método.
Rumbaugh 1991.
Una operación es una función o
una transformación a la cual puede ser aplicada para o por
los objetos en una clase. Contratar, despedir, y pagar utilidades
son operaciones en la clase Compañía. Abiertas,
cerradas, escondidas, y desplegadas son las operaciones de la
clase ventana. Todos los objetos en una clase comparten las
mismas operaciones.
Shlaer y Mellor 1992.
Tomadores de acontecimientos. Define una
operación publicada que corresponde a cada acontecimiento
generado por el objeto bajo consideración. Tales
operaciones publicadas se conocen como tomadores de
acontecimientos. Hay dos casos a considerar:
- si el acontecimiento generado por el generador de
acontecimientos no causa un nuevo caso del objeto a ser
creado, define a tomador correspondiente del acontecimiento
como operación del caso. Lo nombra: "Acontecimiento
Tomado" - si el acontecimiento generado por el generador de
acontecimientos hace un nuevo caso del objeto a ser creado,
define a tomador correspondiente del acontecimiento como
operación de la clase y lo nombra: Toma y
Crea
Wrifs-Brock 1990.
Cuando un objeto recibe un mensaje, realiza la
operación solicitada ejecutando un
método.
ANALISIS
En el repaso de cada definición de la
"Operación", solamente Booch indica que el
método y la operación son equivalentes. Algunos
métodos visualizan los métodos de un objeto de una
perspectiva externa, mientras que otros se centran en los
métodos de un objeto de una perspectiva interna. El
método solamente de Martin y de Odell no hace caso de la
aplicación métodos externos o internos.
Metodología | Operación = | Externo | Interno | Estado |
Berard | X | X | ||
Booch | X | X | ||
Coad y Yourdon | X | |||
Embley | X | |||
Martin y Odell | X | |||
Rumbaugh | X | X | ||
Shlaer y Mellor | X | X | X | |
Wirfs-Brock | X |
D. DEFINICIÓN DE "METACLASE" EN CADA
METODOLOGIA
Berard 1992.
Metaclase: una clase que sus isntancias son asi mismos
clases.
Booch 1991.
Metaclase: la clase de una clase; una clase que sus
instancias son asi mismos clases
Coad y Yourdon 1990.
No se hace ninguna mención explícita de
metaclase.
Embley y Kurtz 1990.
No se hace ninguna mención explícita de
metaclase.
Martin y Odell 1992.
No se hace ninguna mención explícita de
metaclase.
Rumbaugh 1991.
Las clases se pueden también considerar como
objetos, pero son meta-objetos y objetos no del mundo real. El
objeto del descriptor de la clase tiene características, y
alternadamente tienen sus propias clases, que se llaman
metaclases. Tratar todo como objeto proporciona una puesta en
práctica más uniforme y una mayor funcionalidad
para solucionar problemas complejos. Metaclase: una clase que
describe otras clases.
Shlaer y Mellor 1992.
No se hace ninguna mención explícita de
metaclase.
Wrifs-Brock 1990.
No se hace ninguna mención explícita de
metaclase.
E. SIMBOLOGIA UTILIZADA PARA REPRESENTAR LOS
CONCEPTOS POR BOOCH, COAD & YOURDON, Y
RUMBAUGH
OBJETOS
CLASES
ASOCIACION
HERENCIA
AGREGACION
F. COMO LIDIA EL METODO CON CONCEPTOS QUE SON MAS
GRANDES Y QUE PUEDEN SER REPRESENTADOS RAZONABLEMENTE POR UNA
CLASE
Berard 1992.
El dominio del análisis orientado a objetos
intenta identificar los artículos reutilizables
localizados alrededor de los objetos, ejem clases, de instancias,
sistemas de objetos interactuando, y kits.
Kit: una colección de objetos (ejem, clases,
metaclasses, instancias de no-clase, otros kits, y los sistemas
de objetos interactuando) que apoyan a un solo concepto, grande,
coherente, orientado al objeto, ejem, ventanas, interruptores, y
pólizas de seguro. Puede de
hecho haber una cierta conexión física entre
algunos miembros de un kit dado. Sin embargo, los kits son
"granulares," es decir, mientras que todos los componentes de un
kit son lógicamente relacionados, allí son muy
pocas conexiones físicas las que los unen.
Sistema de objetos interactuando: una colección
de objetos (ejem, clases, metaclasses, instancias de no-clase,
kits, y otros los sistemas de objetos interactuando) todos
aquellos que apoyan un concepto solo, grande, coherente,
orientado al objeto, y en cuales allí deben ser una
conexión física directa o indirecta entre cualquier
dos objetos arbitrarios dentro de la colección.
Además, los sistemas de objetos interactuando tienen por
lo menos uno interno, independientemente del control
ejecutado
Booch 1991.
Sin embargo, la estructura de la clase de un sistema
grande puede contener varios cientos o algunos miles de clases.
El intentar poner todas estas clases en un diagrama de la
clase llega a ser poco manejable. Para ocuparse de este problema,
necesitamos algunos medios de
organización de clases en pedazos
significativos, que nos conduce a la idea de una categoría
de clase.
… el dominio del análisis intenta identificar
las clases y los objetos que son comunes a todos los usos dentro
de un dominio dado, tal como un software de la contabilidad.
… subsistema una colección de módulos,
algunos de los cuales son visibles a otros subsistemas y otros de
las cuales se ocultan.
Coad y Yourdon 1990.
Tema. Un tema es un mecanismo para dirigir a un lector
(analista, experto del dominio del problema, encargado, cliente) a
través de un modelo grande, complejo. Los temas son
también provechosos para los paquetes del trabajo de
la
organización en proyectos
más grandes, basado sobre investigaciones
iniciales de OOA.
Embley y Kurtz 1990.
Una clase de alto nivel de objetos agrupa las clases de
los objetos, sistemas de relaciones, y notas en una sola clase
objeto.
Martin y Odell 1992.
No se hace ninguna mención explícita de
esto.
Rumbaugh 1991.
Subsistema un componente importante de un sistema
organizado alrededor de un cierto tema coherente. Un sistema se
puede dividir en subsistemas usando particiones o capas. Sistema:
colección organizada de componentes que
interactúan. Partición: un subsistema que povee un
tipo de servicio; una partición puede por si misma
construir subsistemas de nivel mas bajo. Capas: un subsistema que
provee múltiples servicios, todos los cuales estan en el
mismo nivel de abstracción, construye en sistemas de nivel
bajo de abstracción.
Shlaer y Mellor 1992.
Mientras que un dominio pequeño (consistiendo en
cincuenta o pocos objetos) se puede analizar generalmente como
unidad, los dominios grandes se deben particionar para hacer que
el análisis sea una tarea manejable. Para hacer tal
particionamiento, nos aprovechamos del hecho de que los objetos
en un modelo de información tienden a formar racimos:
grupos de objetos que son interconectados el uno con el otro por
muchas relaciones. Por el contrario, relativamente pocas
relaciones conectan objetos en diversos racimos. Al particionar
un dominio, dividimos el modelo de la información de modo
que permanezcan los racimos intactos… Cada sección del
modelo de información entonces se convierte en un
subsistema separado. Observe que cuando el modelo de
información se particiona en subsistemas, cada objeto
está asignado a exactamente un subsistema.
Wrifs-Brock 1990.
Hemos estado hablando de clases como si fueran las
únicas entidades conceptuales que componían una
aplicación. Pero dependiendo de la complejidad de su
diseño, los varios niveles de la encapsulación se
pueden jerarquizar, una dentro del otro… Un subsistema es un
sistema de clases (y posiblemente de otros subsistemas) que
colaboran para satisfacer un sistema de responsabilidades. Aunque
no existen los subsistemas mientras que el software se ejecuta,
son entidades conceptuales útiles.
Los aplicaciones son programas completos. Una simulación
completamente desarrollada, un sistema del procesamiento de
textos, una hoja de cálculo,
una calculadora, o un sistema del pago de la nómina son
ejemplos de aplicaciones.
G. ENFOQUE A LA ORIENTACION DE OBJETOS
Solamente Booch y Berard tienen una cantidad
significativa de texto en describir el dominio del
análisis orientado a objetos.
Shlaer y Mellor sugieren que los objetos se puedan
localizar usando las fuentes
siguientes:
- Cosas tangibles (avión, una pipa, una
computadora) - Roles realizados por personas u organizaciones (doctor, paciente,
corredor) - Incidentes (vuelo, accidente,
funcionamiento) - Interacciones (compra, boda, una red
eléctrica) - Especificaciones (tipos de pólizas de
seguro)
Coad y Yourdon recomiendan la busqueda de objetos con
las siguientes fuentes:
- Estructuras
- Otros Sistemas
- Dispositivos
- Cosas o acontecimientos recordados
- Los roles jugados
- Procedimientos operacionales
- Sitios
- Unidades de la organización
Estas dos aproximaciones, aunque son útiles, son
limitados.
Booch, Berard, y Wirfs-Brock parecen ser los más
orientados al objeto, con su énfasis terminante en
objetos, y el bajo enfoque en asociaciones y
relaciones.
Coad y Yourdon parecen ser los siguientes, con las
carácterísticas de los datos (las
cualidades y las variables de
la isntancia).
Después Rumbaugh, Embley y Kurtz, y Shlaer y
Mellor, con un énfasis fuerte en asociaciones y relaciones
casi en un nivel que hace a estos pares de los artículos
de objetos.
Martin y Odell son los menos orientados a objetos,
aparentemente presentando extensiones leves a la ingeniería de información con una
orientación del comportamiento muy pesada.
A. COMPONENTES DE LA NOTACIÓN DE LAS
MÉTODOLOGIAS
Cada metodología es caracterizada por un sistema
específico de modelos (componentes de la
notación)
Berard 1992.
- Diagrama Objeto-Mensaje
- Diagrama Semántica de Red
- Diagrrama Transición de Estados
- Gráfica Petri-net
- Diagrama de Tiempos
- Kit
- Sistema de Interacción de
Objetos - Gráfica de la Unidad del
Programa
Booch 1991.
- Diagrama de Clases
- Diagrama de Objetos
- Diagrama de Transiciones de Estados
- Diagrama de Tiempos
- Diagrama de Módulos
- Diagrama de Procesos
Coad y Yourdon 1990.
- El símbolo de clase de OOA, representando una
clase, sus cualidades, y sus servicios. - El símbolo de OOA Clase-y-Objeto
- Notación de la estructura
Generalización-Especialización - Notación de la estructura
Entero-Parte - Notación del temas
- Notación de atributos
- Notación de la conexión de la instancia
(Instance Connection notation) - Notación de servicio
- Notación Diagrama Objeto Estado
- Notación de Grafica de Servicio
Embley y Kurtz 1990.
- Modelo Objeto-Relación (ORM)
- Alto-Nivel ORM
- Estado Red
- Alto Nivel del Estado Red
- Diagrama de Interacción
- Alto-Nivel del Diagrama de
Interacción
Martin y Odell 1992.
- Diagrama de Estructura de Datos
- Diagrama de la Jerarquía
Objeto-Generalización - Diagrama Objeto-Relación
- Diagrama de composición de Objetos
- Diagramas de acción
- Gráficas de Estructura (no muestra
ejemplos) - Tablas declarativas. (no muestra
ejemplos) - Diagramas Estado-Cambio o
Diagramas Transición Estado - Diagramas de Evento o Esquema de Eventos
- Diagramas de Flujo de Objetos
- Herramientas para el diseño
gráfico de la interfaz del usuario
Rumbaugh 1991.
- Modelo Objeto utilizado para describir clases,
objetos, atributos, operaciones, especializaciones,
generalizaciones y herencias - Modelos dinámicos los cuales consisten en:
Ecenarios, Traceabilidad de eventos,
Diagramas de estado, Jerarquia de eventos, Diagramas
concurrentes de estado, Diagramas extendidos de estado por
sincronización y ocurrencia de actividades - Modelos funcionales consistentes en: Diagrama de
flujo de datos, Diagramas de
flujo de control - Arquitectura del sistema
Shlaer y Mellor 1992.
- Diagrama de Estructura de
Información - Diagrama de repaso de la Estructura de
Información - Grafica de Dominio
- Matriz del Proyecto
- Modelo de Relación del Subsistema
- Modelo de Comunicación del Subsistema
- Modelo de Acceso al Subsistema
- Modelo de Información
- Descripción de Objetos y Atributos
- Descripción de Relaciones
- Modelo de Comunicación de Objetos
- Lista de Eventos
- Modelo de Acceso a Objetos
- Tabla de Estados del Proceso
- Modelo de Estado
- Diagrama de Flujo de la Acción de
Datos - Descripcion de Procesos
- Diagrama de Herencias
- Diagrama de Dependencias
- Diagrama de Clases
- Gráfica de Estructura de Clases
Wirfs-Brock 1990.
- Tarjeta de Clases
- Tarjeta de Clases con Responsabilidades
- Tarjeta de Clases con Colaboradores
- Una Tarjeta de Clase con una Delegación de
Subsistema - Jerarquías
- Modelo de Interfaz del Usuario
- Grafica de Colaboraciones
- Tarjeta de Subsistemas con
Delegaciones.
B. REPRESENTACIONES GRAFICAS DE
ALGUNOS DIAGRAMAS UTILIZADOS POR BOOCH, COAD & YOURDON, Y
RUMBAUGH
BOOCH
Para ver el gráfico seleccione la
opción "Descargar"
COAD & YOURDON
Para ver el
gráfico seleccione la opción
"Descargar"
RUMBAUGH
Para ver el
gráfico seleccione la opción
"Descargar"
C. CONCEPTOS ESTÁTICOS QUE LA NOTACIÓN
ES CAPAZ DE EXPRESAR
Se consideraron los siguientes conceptos:
- Agregación: ¿De qué objetos
componentes se construye un objeto compuesto? - Especialización: ¿Cómo es un
objeto representado siendo una generalización, o la
especialización de otro objeto? - Comunicación: ¿Cómo los
objetos mostrados se comunican unos con otros? (enviandose
mensajes) - Módulo de Interfaz: ¿Cómo son
las implementaciones físicas de los objetos
representados? - Calificaciones para la reutilización:
¿Cómo un caso específico de un objeto se
representa para ser utilizado por otra clase?
Metodología | Agregación | Especialización | Comunicación | Módulo de | Calificaciones para la |
Berard | Red de Semantica | Red de Semantica | Diagrama Objeto Mensaje | Grafica de la unidad del | Red de Semantica |
Booch | Diagrama de Clases | Diagrama de Clases | Diagrama de Clases | Modulo | Diagrama de Objetos |
Coad y Yourdon | Entero-Parte | Estrcutura | Mensaje | ||
Embley | Modelo Relacion Objeto | Modelo Relacion Objeto | Modelo Relacion Objeto | ||
Martin y Odell | Diagrama de composicion de | Diagrama de la Jerarqia Objeto | Diagramas de flujo del | ||
Rumbaugh | Modelo del Objeto | Modelo del Objeto | Escenario | ||
Shlaer y Mellor | Herencia | Modelo Comunicacion de | Diagrama de clases | ||
Wirfs-Brock | Tarjeta de Clases | Jerarquias | Colaboradores |
D. CONCEPTOS DINÁMICOS QUE LA NOTACIÓN
ES CAPAZ DE EXPRESAR
La representación de los cambios de estado, la
sincronización, y en cierta forma las interacciones del
objeto son elementos esenciales para modelar el comportamiento de
los sistemas.
Metodologia | Cambios de Estado | Tiempos |
Berard | Diagrama Transicion Estado / | Diagrama de Tiempos |
Booch | Diagrama Transicion | Diagrama de Tiempos |
Coad y Yourdon | Diagrama Estado | |
Embley | Red de Estado | Red de Estado |
Martin y Odell | Cambios de Estado | |
Rumbaugh | Diagrama de Estado | Estado Extendido |
Shlaer y Mellor | Modelo de Estado | |
Wirfs-Brock |
E. REGLAS EXPLÍCITAS PARA DEFINIR LOS
SÍMBOLOS DE LAS NOTACIONES
Cada método fue repasado para determinar si los
símbolos del método fueron definidos
explícitamente, y si así es, donde se definieron; y
si existen ejemplos.
Berard | La notación no es formalmente definida. Se |
Booch | La notación se documenta en parte de su |
Coad y Yourdon | Proporciona las reglas específicas para la |
Embley | La notación es formalmente definida en el |
Martin y Odell | Se define la notacion en uno de sus capitulos y |
Rumbaugh | La notación si se define en su |
Shlaer y Mellor | La notacion es formalmente definida a traves de |
Wirfs-Brock | La notación no se define formalmente, pero |
Además, de la definición de la
semántica de las notaciones, se buscaron también
ejemplos y heurística para la construcción de
modelos.
Metodologia | Sintaxis Definida | Semántica | Provisión de | Heurísticas |
Berard | X | X | ||
Booch | X | X | X | X |
Coad y Yourdon | X | X | X | X |
Embley | X | X | X | X |
Martin y Odell | X | X | X | |
Rumbaugh | X | X | X | X |
Shlaer y Mellor | X | X | X | X |
Wirfs-Brock | X | X | X | X |
En general, cada notación (excepto Berard) provee
una definición explícita de la semántica de
su notación, ejemplos y heurística. En muchos casos
los ejemplos son bastante completos, estos son, de los modelos
requeridos para un problema específico, o de una variedad
de problemas.
E. MECANISMO DE PARTICION DENTRO DE LA
NOTACION
Mientras que el tamaño de un sistema aumenta, se
requiere un cierto mecanismo para limitar la visibilidad de la
información solamente a esos objetos de interés en
un momento particular. Estos son los mecanismos que proporciona
cada metodología:
Metodología | Mecanismo de Partición |
Berard | Kits, sistemas de Interaccion de |
Booch | Subsistemas, Procesadores |
Coad y Yourdon | Temas |
Embley | Vistas de Alto Nivel |
Martin y Odell | * |
Rumbaugh | Subsistemas |
Shlaer y Mellor | Subsistemas |
Wirfs-Brock | Subsistemas y Frameworks |
* Martin y Odell mencionan "reinos" y "especificaciones
del reino" en su glosario, pero no
proporcionan ninguna referencia de cómo ésta se
relaciona con la partición del sistema.
A. PASOS DEL PROCESO DE DESARROLLO DE CADA
METODOLOGÍA
Berard 1992.
- Analisis Orientada a Objetos
- Identificacion de fuentes y requerimientos de
informacion - Caracterizaer las fuentes y requerimientos
deinformación - Identificar objetos candidatos
- Construir los modelos orientados a objetos de ambos
problemas, y de la solucion potencial - Re-localizar la informacion alrededor de los
apropiados candidates de objectos - Seleccionar, crear, y verificar objetos
candidatos - Asignar los objetos candidatos a las apropiadas
secciones de los requerimientos especificados de la
orientacion a objetos (OORS) - Desarrollar y refinar la precisa y concisa
descripcion del sistema
- Diseño Orientado a Objetos
- Identificacion de los Objetos
Candidatos - Desarrollo de un modelo de solucion de orientacion
a objetos - Identificar objetos de interes del
modelo - Asociar atributos con las operaciones de
interes - Identificar operaciones afectadas por, y requeridas
por, los objetos candidatos - Identificacion de operaciones de
interes - Asociacion de atributos con las operaciones de
interes - Manejo de Operaciones compuestas
- Descomposición a operaciones
primitivas - Desemparejamiento de objetos
- Seleccionar, crear, y verificar objetos para
diseño - Unir objetos y operaciones
- Examinar objetos para ser completados
- Decidir sobre el lenguaje de programacion de
objetos - Identificacion de Objetos durante el
analisis - Idetificacion de Objetos durinte el
diseño - Crear modelos graficos de orientacion a
objetos - Establecer la interface para cada articulo
orientado a objetos - Implementar cada articulo orientado a
objetos
- Refinar la interface de objetos
- Refinar los otros objetos
- Aplicar recursividad al proceso de desarrollo
orientado a objetos
Booch 1991.
- Diseño de Orientacion a Objetos
- Identificación de Clases y
Objetos - Identificar las Semanticas de Clases y
Objetos - Identificar las relaciones entre Clases y
Objetos - Implementación de Clases y
Objetos
Coad y Yourdon 1990.
- Analisis orientado a Objetos
- Identificar Objetos
- Identificar Estructuras
- Especialización-Generalización de
Estructuras - Estructuras de Entero-Parte
- Estructuras Múltiples
- Definición de Temas
- Definición de Estructuras
- Identificación de los Atributos
- Posicionar los Atributos
- Identificación de las instancias de
Conección - Checar los Casos Especiales
- Especificar los Atributos
- Definición de Servicios
- Identificación del Estado del
Objeto - Identificación de los Servicios
Requeridos - Identificación de los Mensajes de
Conección - Especificar los Servicios
- Poner el conjunto de documentos OOA
juntos
- Identificación del Estado del
- Diseño de Orientación a
Objetos
Diseñar el componente del dominio del
problema
- Diseño de la reutilización y Clases
de Programación - Agrupacionde Clases
Problema-Dominio-Especificación - Establezcer un protocolo
agregando una clase de la generalización - Acomodar el nivel apoyado de la
herencia - Mejora del Funcionamiento
- Apoyo del Componente de la Administración de
Datos - Agregar los Componentes de Nivel
Inferior - Revisar y desafíar las adiciones a los
resultados de OOA
Diseñar el Componente Humano de la
Interacción
- Clasificación de Humanos
- Descripción de los Humanos y los escenarios
de las Tareas - Diseño de la Jerarquía del
Comando - Diseño de la Interacción
Detallada - Continuación del Prototipo
- Diseño de las Clases de los Compnentes de la
Interacción Humanas - Diseño, Contabilidad para el GUI ( cuando es
applicable )
Diseño del componente del Manejo de
tareas
- Cuando las tareas sean requeridas
- Identificar las Tareas Manejo-Evento
- Identificar las Tareas Reloj-Conducidas
- Identificar las tareas de Prioridad y las Tareas
Críticas - Identificar un Coordinador
- Desafiar cada Tarea
- Definir cada Tarea
Diseño del Componente del Manejo de
Datos
- Aproximación selecta de la
administración de datos - Determinar las herramientas del manejo de
datos - Diseñar el componente del Administrador
de Datos
Embley y Kurtz 1990.
- Analisis de los Sistemas Orientado a
Objetos
- Construcción de Modelos
Objeto-Relación - Costruccion de Modelos
Objeto-Comportamiento - Construcción de Modelos Objeto
Interacción - Integrar los Modelos
Martin y Odell 1992.
- Analisis del Comportamiento Orientado a
Objetos
- Definir las Metas del Analisis
- Clarificar el Tipo de Evento
- Generalizar el Tipo de Evento
- Definir las Condiciones de
Operación - Identificar las Causas de
Operación - Refinar los Resultados del Ciclo
Rumbaugh 1991.
- Analisis
2Escribir u obtener una descripción inicial del
problema (declaración del problema)
3Construir in modelo del Objeto
- Identificar Clases de los Objetos
- Comenzar un diccionario de
datos que contenga descripción de Clases,
Atributos y Asociaciones - Agregar asocioaciones entre Clases
- Agregar los atributos para los Objetos y sus
ligas - Organizar y simplificar las clases del objeto
usando herencia. - Probar los caminos de acceso usando panoramas e
iterando los pasos antedichos como necesarios - Agrupar las clases en los módulos, basados
en el acoplador cercano y función
relacionada.
4Desarrollar un Modelo Dinámico
- Prepar los escenarios de las secuencias
típicas de la interacción. - Identificar Eventos entre Objetos y preparar una
traciabilidad de Eventos para cada Escenario - Preparar un organigrama
del Evento para el sistema. - Desarrollar un diagrama de estado para cada clase que
tenga comportamiento dinámico importante - Comprobar para saber si hay consistencia y lo
completo de los Eventos compartidos entre los diagramas de
estado.
5Construir un Modelo Funcional
- Identificar los valores de la entrada y de la
salida. - Usar diagramas de flujo como sean necesarios para
mostrar la dependencia funcional - Describir lo que hace cada función
- Identificación de los contrastes
- Especificar los criterios de la
optimización.
6Verificar, iterar, y refinar los tres
modelos
- Agregar operaciones claves de lo Funcional al Objeto
Modelo - Verificar la consistencia y lo completo de las
Clases, Atributos, de Asociaciones, y de
Operaciones - Desarrollar modelos más detallados para
explorar y para verificar los tres modelos - Iterar los pasos antes mencionados tanto como sean
necesarios para acompletar el analisis
7Diseño del Sistema
Página anterior | Volver al principio del trabajo | Página siguiente |